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Abstract.  As  the  potential  for  highly  destructive  cyberattacks  grows,  organizations 
must  ensure  that  their  procurement  agents  acquire  high  quality,  secure  software.  ISO 
1 2207  and  the  Software  Assurance  Competency  Model,  when  used  together,  pro¬ 
vide  a  clear  view  of  the  activities,  knowledge,  and  competencies  required  to  procure 
secure  software. 

The  Benefit  of  Standardized  Acquisition 

Gartner  forecasts  that  the  worldwide  dollar-valued  IT  spend¬ 
ing  forecast  will  grow  3.1  %  in  201 4,  reaching  $3.8  trillion  [1  ]. 
Considering  the  magnitude  of  this  investment,  organizations 
should  work  hard  to  ensure  the  effective  acquisition  of  systems 
and  software.  This  task  is  a  complicated  one;  the  success  or 
failure  of  any  acquisition  effort  depends  on  the  capability  of  the 
individuals  who  do  the  work,  and  those  individuals’  capability 
depends  on  knowledge  and  experience.  While  an  experienced 
and  knowledgeable  procurement  agent  may  deliver  the  desired 
result,  one  who  is  inexperienced  or  incapable  may  bring  about 
a  disaster.  Establishing  capability  requirements  for  every  person 
involved  in  the  acquisition  process  is  vital  for  organizations  to 
preserve  their  investment  in  technology. 

It  is  essential  to  use  standard  criteria  to  judge  the  perfor¬ 
mance  of  any  task;  standard  criteria  allow  actions  to  be  judged 
objectively.  Having  a  standard  set  of  criteria  also  ensures 
coordinated  management  of  the  process.  Though  the  benefits  of 
coordinated  management  are  manifold,  the  primary  advantage 
is  that  defining  a  process  enables  repeatability.  Looking  back, 
the  entire  decade  of  the  1 990s  seems  to  have  been  devoted 
to  detailing  the  benefits  of  repeatable  processes.  That  think¬ 
ing  was  probably  best  expressed  in  A  Discipline  for  Software 
Engineering  [2].  The  justification  for  a  well-defined,  documented, 
and  systematically  executed  process  is  that  it  can  be  more 
effectively  managed  and  continuously  improved  [2].  A  single, 
comprehensive  set  of  standard  criteria  to  guide  the  work  also 
ensures  efficient  communication  between  participants,  which,  in 
turn,  ensures  a  more  suitable  final  product. 

Repeatability  requires  consistent  execution  of  the  fundamen¬ 
tal  activities  of  a  process.  According  to  conventional  wisdom 
within  the  software  industry,  standards  convey  those  requisite 
activities.  Standards  define  the  fundamental  requirements  for 
the  performance  of  a  given  process.  A  properly  written  and 
administered  standard  will  ensure  that  every  participant  in  the 
process  knows  and  follows  principles  and  practices  that  have 
track  records  of  success.  Concerning  this  discussion,  there  are 
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several  official  and  quasi-official  standards  for  acquisition.  The 
standards  for  acquisition  include  IEEE  1 062-1998,  an  eight- 
page  collection  of  high-level  recommendations  for  ensuring 
quality  in  software  acquisition  [3].  There  are  guidelines  that 
provide  recommendations  for  the  security  testing  of  government 
off-the-shelf  (GOTS)  and  commercial  off-the-shelf  (COTS)  prod¬ 
ucts  [4].  However,  these  recommendations  in  no  way  constitute 
a  complete  process.  The  Common  Body  of  Knowledge  to  Pro¬ 
duce  Acquire  and  Sustain  Secure  Software  itemizes  a  complete 
set  of  principles  and  practices  for  secure  acquisition  [5].  How¬ 
ever,  this  white  paper  does  not  provide  general  guidance  [6]. 

The  almost  total  absence  of  comprehensive  lifecycle  recom¬ 
mendations  for  acquisition  might  be  explained  by  the  dominant  role 
of  ISO  1 2207-2008,  both  internationally  and  in  the  United  States 
[7].  That  standard  documents  a  comprehensive  set  of  activities  and 
supporting  tasks  to  establish  effective  lifecycle  acquisition  of  sys¬ 
tem  and  software  products.  The  standard  dictates  a  complete  set 
of  highly  interdependent  lifecycle  activities  for  proper  execution  of 
the  supply  and  reuse  process,  in  addition  to  explicit  acquisition  rec¬ 
ommendations.  The  standard  also  provides  comprehensive  advice 
about  to  how  to  carry  out  the  ancillary  activities  that  are  necessary 
to  support  those  processes,  such  as  documentation,  software  qual¬ 
ity  assurance,  and  configuration  management. 

Factoring  the  21st  Century  into  the  Equation 

All  of  the  existing  standards  for  acquisition  could  serve  as  a 
basis  for  structuring  a  repeatable  lifecycle  acquisition  function. 
However,  with  the  exception  of  the  Common  Body  of  Knowl¬ 
edge  to  Produce  Acquire  and  Sustain  Secure  Software,  they 
are  all  oriented  toward  assurance  of  product  quality.  Though 
most  of  the  standard  activities  associated  with  product  qual¬ 
ity  (e.g.,  planning,  testing,  reviews,  audits)  still  have  currency  in 
this  discussion,  the  ever-increasing  threats  in  cyberspace  have 
added  a  new  dimension  to  the  requirements  for  a  capable  and 
successful  procurement  process.  Thus,  it  is  critical  that  acquirers 
adopt  and  follow  assurance  practices  to  ensure  that  products 
not  only  operate  as  intended,  but  also  have  sufficient  integrity  to 
withstand  attack. 

The  need  for  secure  products  makes  the  problems  associated 
with  ensuring  the  quality  of  the  purchased  product  almost  nos¬ 
talgically  simple.  A  recent  report  summarizes  the  security  issues 
facing  all  acquirers;  the  report  uses  five  categories— each  with  a 
different  implication  for  acquirers— to  classify  these  concerns  [8]: 

•  installation  of  malicious  logic  on  hardware  or  software 

•  installation  of  counterfeit  hardware  or  software 

•  failure  or  disruption  in  the  production  or  distribution 
of  critical  products  or  services 

•  reliance  upon  a  malicious  or  unqualified  service 
provider  for  the  performance  of  technical  service 

•  installation  of  unintentional  vulnerabilities  on 
software  or  hardware 

These  categories  highlight  a  central  question:  “Do  acquisition 
personnel  have  the  capability  to  ensure  that  purchased  system 
and  software  products  are  free  of  these  threats?” 

Though  the  past  decade  has  produced  a  number  of  acceptable 
methods  for  assuring  the  security  of  the  product  [9,  1 0],  ensur¬ 
ing  the  ability  of  the  individual  worker  to  apply  these  approaches 
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is  difficult.  A  new  model  from  the  Carnegie  Mellon  University 
Software  Engineering  Institute  (SEI),  the  Software  Assurance 
Competency  Model,  establishes  a  foundation  for  assessing  the 
capability  of  software  assurance  professionals  [1 1].  The  model 
can  be  used  by  individuals  to  assess  their  own  capabilities  and 
professional  goals,  and  by  organizations  to  assist  in  staffing  and 
building  teams  with  appropriate  competencies.  At  present,  there 
is  not  a  competency  exam  associated  with  the  model,  which  is 
intended  to  be  instantiated  by  organizations  for  their  own  use. 

This  model,  which  has  been  endorsed  by  the  IEEE  Com¬ 
puter  Society,  portrays  the  requisite  competencies  for  software 
assurance  work  across  a  range  of  knowledge  areas  [11].  The 
competency  areas  captured  in  this  model  are  1)  Assurance 
Across  the  Lifecycle,  2)  Risk  Management,  3)  Assurance 
Management,  4)  Assurance  Assessment,  5)  System  Security 
Assurance,  6)  System  Functionality  Assurance,  and  7)  System 
Operational  Assurance.  The  model  is  further  decomposed  into 
individual  units  based  on  knowledge  and  skills.  Those  knowl¬ 
edge  and  skill  units  can  be  ranked  at  competency  levels  1 
through  5  [9].  The  Software  Assurance  Competency  Model 
provides  a  common  definition  of  the  activities  required  to  ensure 
a  secure  product,  and  it  uses  a  competency-based  evaluation 
scheme.  The  model’s  knowledge  and  competency  stipulations 
can  be  combined  with  the  acquisition  process  recommendations 
from  ISO  1 2207  to  define  a  set  of  standard,  competency-based 
acquisition  processes  for  any  organization.  This  amalgamation 
can  then  be  used  to  judge  whether  a  given  acquisition  process 
is  being  performed  at  a  sufficient  level  of  capability. 

A  Competenq^-Based  Model  for  Secure 
Acquisition  Practice 

The  SEI  Software  Assurance  Competency  Model  comprises 
seven  competency  areas,  which  are  decomposed  into  20  knowl¬ 
edge  units.  Some  of  these  knowledge  units  are  devoted  to  ele¬ 
ments  of  software  work  that  do  not  involve  acquisition.  However, 
1 3  of  those  20  units  can  apply  to  ensuring  a  secure  acquisition: 
Software  Lifecycle  Processes,  Software  Assurance  Processes 
and  Practices,  Risk  Management  Concepts,  Risk  Management 
Processes,  Software  Assurance  Risk  Management,  Assurance 
Assessment  Concepts,  Measurement  for  Assessing  Assurance, 
Making  the  Business  Case  for  Assurance,  Managing  Assurance 
Compliance  Considerations,  Assurance  Ethics  and  Integrity 
in  Creation,  Acquisition,  and  Cperation  of  Software,  Systems 
Assurance  Technology,  Assurance  in  Acquisition,  Cperational 
Monitoring,  System  Control,  and  Cperational  Procedures  [1  1]. 

Each  of  these  knowledge  units  is  tied  to  a  staged  set  of 
competencies.  Table  1  provides  the  general  definition  of  these 
requisite  abilities  [1 1  ]. 

Integrating  Standard  Acquisition  Practices  with 
Competency  Requirements 

The  areas  in  the  SEI  Software  Assurance  Competency 
Model  cover  the  entire  software  and  system  assurance  process. 
Though  the  SEI  model  does  not  specifically  designate  compe¬ 
tencies  for  acquisition,  ISC  1 2207  does  specify  an  end-to-end 
set  of  acquisition  practices.  These  practices  have  been  stan¬ 
dardized  since  1995  [7].  Table  2  summarizes  required  practices 
for  ISC  12207. 


L1  -  Technician 

Possesses  technical  knowledge  and  skills,  typically  gained  through 
a  certificate  or  an  associate  degree  program,  or  equivalent 
knowledge  and  experience 

L2- 

Professional 

Entry  Level 

Possesses  application-based  knowledge  and  skills  and  entry-level 
professional  effectiveness;  may  also  manage  a  small  internal 
project,  supervise  and  assign  L1  personnel,  supervise  and  assess 
system  operations,  and  implement  accepted  assurance  practices 

L3  -  Practitioner 

Possesses  breadth  and  depth  of  knowledge,  skills,  and 
effectiveness;  may  also  set  plans,  tasks,  and  schedules  for  in-house 
projects  and  may  define  and  manage  such  projects  and  supervise 
teams  on  the  enterprise  level 

L4  -  Senior 

Practitioner 

Possesses  breadth  and  depth  of  knowledge,  skills,  and 
effectiveness  and  a  variety  of  work  experiences;  has  5  to  1 0  years  of 
experience  and  professional  development;  identifies  and  explores 
software  assurance  practices,  manages  large  projects,  interacts 
with  clients 

L5  -  Expert 

Advances  the  field  by  developing,  modifying,  and  creating  methods, 
practices,  and  principles  at  the  organizational  level  or  higher;  has 
peer/industry  recognition 

Table  1 :  Staged  Competencies  for  Each  Knowledge  Unit 


1.  Initiation 

•  Prepare  a  concept  or  a  need  to  acquire,  develop,  or  enhance  a 
product  or  service 

•  Prepare  a  set  of  requirements,  including  relevant  design,  testing,  and 
compliance  standards 

•  Prepare  a  risk  and  cost-benefit  analysis  for  acquisition 

•  Prepare  a  set  of  acceptance  criteria  and  criteria  for  evaluation 
Prepare  acquisition  plan  based  on  requirements,  analyses,  and  criteria 
defined  in  prior  steps 


2.  Request  for  Proposals 

•  Document  acquisition  requirements  depending  on  acquisition  option 
selected 

•  Define  contract  milestones 

•  Specifically  delegate  implementation  of  requirements  to  responsible 

_ organizational  entity _ 

3.  Contract  Preparation  and  Update 

•  Establish  plans  for  supplier  selection 

•  Institute  and  carry  out  a  negotiation  process  including  contract 
preparation 

•  Institute  a  process  for  change  control _ 

4.  Supplier  Monitoring 

•  Prepare  a  plan  for  supplier  review 

_ *  Systematically  review  supplier  during  product  preparation  period 

5.  Acceptance  and  Completion 

•  Perform  acceptance  reviews  and  testing 

_ •  Institute  systematic  configuration  management _ 

Table  2:  Standard  Acquisition  Steps  for  ISO  12207 

Together,  ISO  1 2207  and  the  SEI  Software  Assurance  Com¬ 
petency  Model  describe  the  skills  and  competencies  required 
to  execute  a  software  acquisition  process.  The  complete  set  of 
acquisition  practices  specified  in  ISO  1 2207  can  be  combined 
with  the  knowledge  units  and  competencies  from  the  SEI  Soft¬ 
ware  Assurance  Competency  Model  to  provide  an  assurance 
knowledge  and  competency-based  description  for  the  standard 
activities  of  software  and  system  acquisition. 

Table  3  presents  a  suggested  amalgamation  of  the  ISO 
1 2207  acquisition  process  requirements  with  the  standard 
knowledge  units  of  the  SEI  Software  Assurance  Competency 
Model  (note:  1 2207  practices  are  in  bold  and  SEI  SwA  Compe¬ 
tency  practices  are  in  italics).  The  associated  SwA  Competency 
levels  can  be  added  to  each  of  the  individual  SEI  knowledge 
units  based  on  the  needs  of  the  situation. 
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Conclusion 

The  ability  to  guarantee  a  secure  acquisition  is 
far  too  important  to  the  well-being  of  any  organi¬ 
zation  to  base  its  activities  on  individual  virtuosity. 
Therefore,  there  is  justification  for  a  well-defined 
model  of  practice.  ISO  1 2207  provides  a  com¬ 
monly  accepted  statement  of  the  complete  set 
of  practices  necessary  to  conduct  system  and 
software  acquisition.  The  acquisition  activities 
and  tasks  specified  in  this  standard  have  been 
accepted  as  correct  for  almost  two  decades  [7]. 
The  Software  Engineering  Institute  has  provided 
a  model  of  the  knowledge  and  competency  levels 
needed  to  assure  software  and  systems.  Combin¬ 
ing  ISO  1 2207  and  the  Software  Assurance 
Competency  model  to  form  a  single  description 
of  the  activities,  knowledge,  and  competencies 
required  to  procure  secure  software  and  systems 
benefits  the  community  as  a  whole. 

The  potential  for  highly  destructive  attacks 
directed  through  acquired  software  and  system 
products  is  a  reality  in  cyberspace.  Whether  the 
adversary  is  a  nation  state  or  a  single  hacker,  it 
is  presently  far  too  easy  to  cause  serious  harm 
through  the  insertion  of  malicious  and  counterfeit 
objects  into  purchased  software  and  systems.  The 
inclusion  of  such  tainted  products  in  our  national 
infrastructure  could  potentially  threaten  our  way  of 
life.  Given  the  swiftness  of  technological  change,  it 
is  excusable  that  organizations  might  not  recognize 
the  emerging  importance  of  purchased  software 
and  systems.  It  is  inexcusable,  however,  to  know 
that  threats  exist  and  to  stand  idly  by  without  doing 
anything  about  the  situation.  This  paper  suggests 
one  approach  organizations  can  take  to  better 
ensure  the  security  of  the  products  they  buy.  ^ 
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ISO  12207  Practice 

SEI  Software  Assurance  Competency  Model  Practice 

Prepare  a  concept  or  a  need  to  acquire, 
develop,  or  enhance  a  product  or  service 

o  Software  Lifecycle  Processes 

o  Making  the  Business  Case  for  Assurance 

o  Ethics  and  Integrity  in  Creation,  Acquisition,  and  Operation 

Prepare  a  set  of  requirements  including 
relevant  design,  testing  and  compliance 
standards 

o  Software  Assurance  Processes  and  Practices 
o  Risk  Management  Concepts 

o  Risk  Management  Processes 

o  Software  Assurance 

o  Risk  Management  Assurance  Assessment  Concepts 
o  Measurement  for  Assessing  Assurance 

Prepare  a  risk  and  cost-benefit  analysis  for 
acquisition 

o  Risk  Management  Concepts 

o  Risk  Management  Assurance  Assessment  Concepts 

o  Making  the  Business  Case  for  Assurance 

o  Assurance  in  Acquisition 

Prepare  a  set  of  acceptance  criteria  and  criteria 
for  evaluation  Software  Lifecycle  Processes 

o  Software  Assurance  Processes  and  Practices 
o  Risk  Measurement  for  Assessing  Assurance 
o  Assurance  in  Acquisition 
o  Operational  Monitoring 

Prepare  acquisition  plan  based  on 
requirements,  analyses,  and  criteria  defined  in 
prior  steps 

o  Software  Lifecycle  Processes 

o  Risk  Management  Concepts 

o  Risk  Management  Processes 

o  Software  Assurance 

o  Managing  Assurance  Compliance  Considerations 
o  Assurance  in  Acquisition 

o  Operational  Monitoring 

Document  acquisition  requirements  depending 
on  acquisition  option  selected 

o  Software  Assurance  Processes  and  Practices 
o  Risk  Management  Processes 
o  Software  Assurance 

o  Risk  Management  Assurance  Assessment  Concepts 
o  Measurement  for  Assessing  Assurance 

Define  contract  milestones 

o  Software  Lifecycle  Processes 
o  Software  Assurance  Processes  and  Practices 
o  Managing  Assurance  Compliance  Considerations 

Specifically  delegate  implementation  of 
requirements  to  responsible  organizational 
entity 

o  Software  Lifecycle  Processes 
o  Management  Concepts 
o  Risk  Management  Processes 
o  Software  Assurance 

o  Risk  Management  Assurance  Assessment  Concepts 

Establish  plans  for  supplier  selection 

o  Making  the  Business  Case  for  Assurance 
o  Managing  Assurance  Compliance  Considerations 
o  Ethics  and  Integrity  in  Creation,  Acquisition,  and  Operation 
o  Assurance  in  Acquisition 

Institute  and  carry  out  a  negotiation  process 
including  contract  preparation 

o  Risk  Management  Processes 
o  Software  Assurance 
o  Assurance  in  Acquisition 

Institute  a  process  for  change  control 

o  Software  Lifecycle  Processes 
o  System  Control 
o  Operational  Procedures 

Prepare  a  plan  for  supplier  review 

o  Software  Assurance  Processes  and  Practices 
o  Risk  Management  Concepts 

o  Risk  Management  Processes 

o  Software  Assurance 

o  Risk  Management  Assurance  Assessment  Concepts 
o  Measurement  for  Assessing  Assurance 
o  Systems  Assurance  Technology 
o  Assurance  in  Acquisition 
o  Operational  Monitoring 
o  System  Control 

Systematically  review  supplier  during  product 
preparation  period 

o  Management  Processes  Software  Assurance 
o  Measurement  for  Assessing  Assurance 

o  Managing  Assurance  Compliance  Considerations 
o  Systems  Assurance  Technology 
o  Assurance  in  Acquisition 
o  Operational  Monitoring 
o  System  Control 
o  Operational  Procedures 

Perform  acceptance  reviews  and  testing 

o  Measurement  for  Assessing  Assurance 
o  Systems  Assurance  Technology 
o  Assurance  in  Acquisition 
o  System  Control 

Institute  systematic  configuration  management 

o  Systems  Assurance  Technology 
o  Operational  Monitoring 
o  System  Control 
o  Operational  Procedures 

Table  3:  Creating  a  Competency-Based  Model  of  Secure  Acquisition  Practice 
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